Keep pack type codes for new objects within 3-bit limit

Assigning ObjectType values 8..16 here breaks pack round-tripping for AI objects: pack headers only carry 3 type bits (see read_type_and_size masking with 0x70), so these IDs cannot be represented and will decode as an invalid type. Any attempt to pack ContextSnapshot/Task/Run/etc. objects will produce pack data that cannot be decoded correctly, causing fetch/transfer failures or dropped objects.

Useful? React with 👍 / 👎.

Expose context snapshot state beyond header metadata

This impl now ends after header(), so external callers can no longer read base_commit_sha/selection_strategy/items/summary or populate items and summary after new(). Because those fields are private, snapshots created through the public API are effectively fixed to an empty payload, which is a functional regression from the previous API surface.

Useful? React with 👍 / 👎.

ContextSnapshot::from_bytes maps JSON decode errors to the generic InvalidObjectInfo, but GitError now has a dedicated InvalidContextSnapshotObject variant. Using the specific variant here (and similarly for the other agent object types) would preserve better error classification and make the new variants actionable.

decode_pack_object returns Ok(None) for the AI object types without consuming the object's compressed payload or advancing offset. This will desynchronize the reader for the next iteration (it will try to parse zlib-compressed bytes as a new object header). Even if you want to skip caching these objects, you still need to read/skip their (compressed) data and update offset accordingly (ideally via a discard/decompress-to-sink helper to avoid allocating the full Vec).

ObjectType::to_u8 assigns values 8..16 for the new AI object types, but the pack object header encoding only has 3 bits for the type (0..7). Because pack/encode.rs shifts this value into the header’s type bits, values >7 will be truncated and encoded as the wrong type (or even 0), and pack/decode.rs can never read back 8..16 from the header. Consider keeping to_u8 limited to valid pack type ids (1..7) and introducing a separate mapping/extension mechanism for AI objects (e.g., store them as Blob in packs and carry the AI subtype inside the object payload/header).

ContextSnapshot keeps base_commit_sha, selection_strategy, items, and summary as private fields but no longer exposes accessors/mutators for them. As a public type this makes it impossible for callers to inspect or build snapshots beyond the header. Consider restoring read accessors (and any needed builders like add_item / set_summary) or making the fields public if external access is intended.

decode_pack_object now uses ObjectType::from_pack_type_u8(type_bits) (pack header 3-bit type field). That decoder can only yield the 1..=7 pack types, so the ObjectType::{ContextSnapshot,..,ToolInvocation} match arm is unreachable. Returning Ok(None) here also wouldn’t advance the reader/offset, which would desync decoding if it ever happened. Suggest removing this arm and instead returning an error for any unsupported pack type bits, or implement a real on-disk encoding for AI objects before introducing a skip path.

This assertion was relaxed to >=, which can mask real decode/caching bugs (e.g. dropped objects due to logic errors) because pack object count should match the number of cached base objects/deltas once processing completes. If AI objects are truly being skipped, it would be better to explicitly track skipped and assert self.number == caches.total_inserted() + skipped (and ensure skipped objects are fully consumed from the stream).

For issue_comment / pull_request_review_comment / pull_request_review events, github.event.pull_request is not present, so this checkout will fall back to github.sha (default branch commit) and the review will run against the wrong code. The previous workflow explicitly resolved and checked out the PR head ref for comment-driven triggers; that behavior likely needs to be preserved (e.g. resolve PR number via gh pr view and fetch/checkout the head SHA/ref).

ObjectType::to_bytes() panics for the delta variants via the catch-all arm (and the message has a typo: "can put"). Since to_bytes() is used in hashing paths (pack/utils.rs, zlib/stream/inflate.rs), a panic here would be a hard crash if a delta type ever leaks into those callers. Consider making the delta cases explicit (and unreachable with a clear message/invariant), or refactor callers so they can’t request a loose-object header for delta-only types.

These new Invalid*Object error variants are currently unused: the AI object from_bytes implementations still map JSON decode failures into the generic InvalidObjectInfo. Either wire the new variants into each object’s parsing (for more actionable errors) or remove them to avoid API/enum bloat.

The Display impl signature uses &mut std::fmt::Formatter without the required lifetime parameter. Formatter is Formatter<'a>, so this should be &mut std::fmt::Formatter<'_> (or import fmt and use fmt::Formatter<'_>), otherwise this won’t compile.